1. Field of the Invention
The present invention relates generally to graphics systems and, more particularly, to graphics system performance optimization techniques.
2. Related Art
Computer graphics systems are commonly used for displaying two- and three-dimensional graphical representations of objects on a two-dimensional video display screen. Current computer graphics systems provide highly detailed representations and are used in a variety of applications.
In a typical computer graphics system, an object or model to be represented on the display screen is broken down into graphics primitives. Primitives are basic components of a graphics display and include, for example, points, lines, triangles, quadrilaterals, triangle strips and polygons. Typically, a hardware/software scheme is implemented to render, or draw, the graphics primitives that represent a view of one or more models being represented on the display screen.
Generally, primitives of a three-dimensional object to be rendered are defined by a host computer in terms of primitive data. For example, when the primitive is a triangle, the host computer may define the primitive in terms of the X, Y, Z and W coordinates of its vertices, as well as the red, green and blue and alpha (R, G, B and xcex1) color values of each vertex. Additional primitive data may be used in specific applications. Rendering hardware interprets the primitive data to compute the display screen pixels that represent each primitive, and the R, G and B color values for each pixel.
A graphics interface is typically provided to enable graphics applications located on the host computer to efficiently control the graphics system. The graphics interface provides specific commands that are used by a graphics application executing on the host computer to specify objects and operations, producing an interactive, three-dimensional graphics environment. Such a graphics interface is typically implemented with software drivers.
For example, the OpenGL(copyright) standard defines an application program interface (API) that provides specific commands that are used to specify objects and operations to produce interactive, three-dimensional applications. (OpenGL is a registered trademark of Silicon Graphics, Inc.). OpenGL is a streamlined, hardware-independent interface designed to be implemented on many different hardware platforms. As such, in computer systems which support OpenGL, the operating systems and graphics application software programs can make calls to the computer graphics system according to the standardized API without knowledge of the underlying hardware configuration. The OpenGL standard provides a complete library of low-level graphics manipulation commands for describing models of three-dimensional objects (the xe2x80x9cGLxe2x80x9d of OpenGL refers to xe2x80x9cGraphics Libraryxe2x80x9d). This standard was originally based on the proprietary standards of Silicon Graphics, Inc., but was later transformed into an open standard which is used in high-end graphics-intensive workstations and, more recently, in high-end personal computers. The OpenGL standard is described in the OPENGL PROGRAMMING GUIDE, version 1.1 (1997), the OPENGL REFERENCE MANUAL, version 1.1 (1997), and a book by Segal and Akeley (of SGI) entitled THE OPENGL GRAPHICS SYSTEM: A SPECIFICATION (Version 1.2), all of which are hereby incorporated by reference in their entirety.
A graphics system typically maintains state values that represent the current state of various aspects of object models. Graphics systems generally behave as a state machine; a specified state value remains in effect until it is changed by the graphics application through the issuance of an API command, also referred to herein as a graphics call, to the graphics system through the graphics software interface. Thus, all vertices are rendered in accordance with a current value of applicable state variables in the graphics system.
By providing detailed control over the manner in which primitives and their vertices are rendered in the graphics system, the graphics software interface provides software developers with considerable flexibility in creating graphics application software programs. A graphics software application may be structured in any one of many different configurations to implement a desired function or to achieve a desired result in the graphics system. For example, graphics applications may generate different graphics call sequences sequence to achieve the same rendering of the same model.
It is well known that some graphics call sequences and the manner in which primitives, vertices and states specified in the sequence are implemented are more efficient than others. That is, although multiple graphics applications may achieve the same rendering of the same model, certain graphics applications may, due to the contents of the graphics call sequence that they generate, cause the graphics system to perform unnecessary operations, or to perform certain operations in a manner that requires greater overhead than is otherwise necessary.
Generally, graphics call sequences generated by a graphics application are stored in a memory prior to being executed by the graphics system. When stored for execution by the graphics system, such graphics call sequences are commonly referred to as a display list. The memory dedicated to the temporary storage of these graphics call sequences is commonly referred to as a display list memory. In conventional graphics systems, overhead is associated with the storage of these graphics call sequences in the display list memory (xe2x80x9cstorage overheadxe2x80x9d). For example, when generating a single graphics primitive using the OpenGL graphics library, a glBegin( ) graphics call is first issued to indicate the start of a particular type of the primitive. The glBegin( ) graphics call is followed by an appropriate number of glVertex( ) graphics calls specifying the vertices of the identified primitive, followed by a glEnd( ) graphics call to indicate the end of the primitive. A number of different graphics calls may be located between a glBegin( )/glEnd( ) graphics call pair. Such graphics calls include graphics vertex calls as well as graphics calls that set state variables. All such graphics calls are referred to herein as vertex-related graphics calls. The glBegin( )/glEnd( ) pair and all vertex-related graphics calls interposed between the two are collectively and generally referred to herein as a primitive data set. Other graphics calls that do not occur between a glBegin( ) and glEnd( ) graphics call are referred to herein as non-vertex-related graphics calls. One particular type of non-vertex-related graphics call is a type of graphics call that alters the modal state of the graphics system. A primitive data set representing, for example, a single independent triangle, includes a glBegln( ) call, followed by three glVertex( ) calls to generate the three vertices of the triangle primitive, followed by a glEnd( ) call. As a result, five graphics calls or commands are processed to generate a single triangle primitive. All five of these commands in the primitive data set are stored in the display list memory. A display list generated by a typical graphics application often contains millions of graphics primitive data sets. The overhead associated with the storage of a large number of primitive data sets in the display list memory can impose a significant burden on the efficiency of the graphics system.
Furthermore, when a primitive data set is executed, execution of the glBegin( ) command at the beginning of each primitive data set typically incurs some execution overhead by the graphics system, such as verifying the validity of the identified primitive, and configuring the graphics hardware to render the specified primitive. Thus, the total execution overhead associated with executing the glBegin( ) commands in a typical graphics call sequence can be significant.
Some graphics system optimization schemes perform post-processing of the display list subsequent to its generation by an application program. Such post-processing techniques generally require that primitive data for all graphics calls which are to be optimized have been generated and stored in the display list memory prior to the performance of the optimization techniques. Once the graphics call sequence is stored in the display list memory, such conventional post-processing techniques analyze the stored display list to determine if it can be optimized. Generally, such conventional post-processing techniques adversely affect the performance of the graphics system. The impact of such processing on run-time operations is so great that such techniques are sometimes performed off-line to analyze the performance of, and identify potential improvements to, the graphics application. Furthermore, removal from the display list of unnecessary graphics calls causes memory fragmentation of the display list memory, adversely impacting the performance of the graphics system.
What is needed, therefore, is a system and method that optimizes graphics call sequences by reducing the storage and/or execution overhead associated with the generation, storage and execution of such sequences.
The present invention is directed to apparatuses and methodologies for use in a graphics system that includes a display list memory to store graphics calls to be executed. In one aspect of the invention, a graphics call sequence optimizer is disclosed. The optimizer optimizes an original graphics call sequence that includes a sequence of graphics calls generated by a graphics application program in accordance with a graphics application program interface (API). The optimizer generates an optimized graphics call sequence that effects a same rendering in the graphics system as the original graphics call sequence. The optimizer includes a primitive command set generator constructed and arranged to receive the original graphics call sequence and to generate a primitive command set for storage in the display list memory. The primitive command set includes a plurality of primitive data sets each comprised of graphics calls of the original graphics call sequence. In one embodiment, the optimizer also includes a display list executor constructed and arranged to retrieve the primitive command set from the display list memory and to execute the primitive command set without performing duplicative operations associated with each primitive data set included in the primitive command set. The primitive command set generator notifies the display list executor that the graphics call sequence stored in the display list memory is a primitive command set. The generator may insert a graphics call in the display list memory adjacent to the primitive data sets to notify the display list executor that the primitive data sets comprise a primitive command set, or communicate such information using other mechanisms or techniques. The plurality of graphics primitive data sets may occur sequentially in the original graphics call sequence and the optimized graphics call sequence may include graphics primitive data sets of differing primitive types.
In one particular embodiment, the API is the OpenGL API. In this embodiment, each of the graphics primitive data sets in the optimized graphics call sequence comprises a glBegin( ) graphics call, a glEnd( ) graphics call and intermediate vertex-related graphics calls. The display list executor is constructed and arranged to generate hardware signals for each glBegin( ) and glEnd( ) graphics call except a first occurring glBegin( ) graphics call and a last occurring glEnd() graphics call in the primitive command set.
In another aspect of the invention, a method for optimizing an original graphics call sequence is disclosed. The original graphics call sequence is generated by a graphics application program in accordance with a graphics application program interface (API) for use in a graphics system that includes a display list memory to store graphics calls to be executed. The original graphics call sequence includes a plurality of graphics primitive data sets. The method comprises the steps of: a) combining a plurality of primitive data sets occurring sequentially in the original graphics call sequence into a primitive command set that includes the plurality of combined primitive data sets and a primitive set command identifying the plurality of primitive data sets as comprising the primitive command set; and b) storing the primitive command set in the display list memory, wherein the primitive command set is included in an optimized graphics call sequence that effects a same rendering in the graphics system as the original graphics call sequence. The optimized graphics call sequence may include graphics primitive command sets of differing primitive types. In one embodiment, the method also includes the steps of: c) identifying the primitive command set in the display list memory; and d) executing the primitive command set in the optimized graphics call sequence stored in the display list memory.
In one embodiment of this aspect of the invention, the API is the OpenGL API. In this embodiment, each of the graphics primitive data sets in the optimized graphics call sequence comprises a glBegin( ) graphics call, a glEnd( ) graphics call and intermediate vertex-related graphics calls. Step d) includes the steps of: 1) outputting a glBegin( ) graphics call; 2) for each primitive data set in the optimized graphics primitive call sequence, performing steps of: (a) outputting internal graphics vertex call sequence of the primitive data set, (b) outputting a signal indicating the end of a primitive data set, and (c) outputting a signal indicating the beginning of a primitive data set; and 3) outputting a glEnd( ) graphics call. Alternatively, step d) includes the step of: 1) generating hardware signals for each glBegin( ) and glEnd( ) graphics call except a first occurring glBegin( ) graphics call and a last occurring glEnd( ) graphics call in the primitive command set.
In a still further aspect of the invention, a computer readable medium encoded with a program for execution on a host computer, the program, when executed on the host computer, performs a method for optimizing an original graphics call sequence including a sequence of graphics calls generated by a graphics application program in accordance with a graphics application program interface (API) to generate an optimized graphics call sequence. The original graphics call sequence including a graphics primitive command set, the method comprising the steps of: a) combining a plurality of primitive data sets occurring sequentially in the original graphics call sequence into a primitive command set that includes the plurality of combined primitive data sets and a primitive set command identifying the plurality of primitive data sets as comprising the primitive command set; and b) storing the primitive command set in the display list memory, wherein the primitive command set is included in an optimized graphics call sequence that effects a same rendering in the graphics system as the original graphics call sequence. Preferably, the method further include the steps of: c) identifying the primitive command set in the display list memory; and d) executing the primitive command set in the optimized graphics call sequence stored in the display list memory.
Various embodiments of the present invention provide certain advantages and overcome certain drawbacks of the conventional techniques. Not all embodiments of the invention share the same advantages and those that do may not share them under all circumstances. This being said, the present invention provides numerous advantages including efficiently executing primitive data sets. Specifically, embodiments of the present invention stores a primitive command set in a display list memory which is subsequently executed by a display list executor. The primitive command set may be stored in a contiguous block of memory. When executed, the display list executor identifies the primitive data sets as belonging to a primitive command set and eliminates processes common to the primitive data sets where possible. This substantially eliminates the time to execute the primitive data sets.
Further features and advantages of the present invention as well as the structure and operation of various embodiments of the present invention are described in detail below with reference to the accompanying drawings. In the drawings, like reference numerals indicate identical or functionally similar elements. Additionally, the left-most one or two digits of a reference numeral identifies the drawing in which the reference numeral first appears.